Skip to content

feat: Allow JWT signing keys to be shared (closes #4699)#6537

Draft
keeganwitt wants to merge 2 commits into
spiffe:mainfrom
keeganwitt:too_many_jwks_keys
Draft

feat: Allow JWT signing keys to be shared (closes #4699)#6537
keeganwitt wants to merge 2 commits into
spiffe:mainfrom
keeganwitt:too_many_jwks_keys

Conversation

@keeganwitt

Copy link
Copy Markdown
Contributor

Pull Request check list

  • Commit conforms to CONTRIBUTING.md?
  • Proper tests/regressions included?
  • Documentation updated?

Affected functionality

  • AWS KMS KeyManager server plugin
  • Azure Key Vault KeyManager server plugin
  • GCP KMS KeyManager server plugin
  • Disk KeyManager server plugin

Description of change
Adds the ability to share signing keys between server instances rather than each instance managing its own key pairs, so that the number of keys that will be exposed in the JWKS endpoint is reduced.

Which issue this PR fixes
#4699

@keeganwitt keeganwitt force-pushed the too_many_jwks_keys branch 3 times, most recently from 705e1fb to 3df263c Compare January 8, 2026 18:20
@sorindumitru

Copy link
Copy Markdown
Member

We've discussing this a bit, here's a summary of the discussions so far (at least the parts I remember):

  • Since this may require experimenting we'd like to start with just the changes in the AWS keymanager. Once we get some familiarity with this mode, we can extend it to other plugins.
  • We'd like to keep the plugin implementation be similar for the two different config options (shared and non-shared keys) so that it does not increase the maintenance burden.
  • This may require some changes in other parts of the code. E.g. how key ids are generated. Each server currently generates a random number for it's key so I think that even with this you'll get N keys in the bundle. We'll likely have to make it more deterministic, maybe based on the public key.
  • It's unclear how well this will work with removal from the bundle. It may just work, but it might depend on TTLs and on when a certain key starts being used.
  • Some feature might not work at all with this, e.g. tainting keys. It would be nice to have some kind of support for this, but it may be hard without the servers communicating between each other.

@sorindumitru

Copy link
Copy Markdown
Member

@keeganwitt, checking in to see if you are still interested in looking at how we can move this forward.

@keeganwitt

Copy link
Copy Markdown
Contributor Author

@keeganwitt, checking in to see if you are still interested in looking at how we can move this forward.

My team hasn't had a chance to test this yet, but yes, I think we want to move forward with fixing this issue.

@amartinezfayo

Copy link
Copy Markdown
Member

@keeganwitt maybe you could join one of the weekly SPIRE Contributor Sync so we can have a discussion around this PR?

@keeganwitt keeganwitt force-pushed the too_many_jwks_keys branch 3 times, most recently from aca4343 to 6e9bb74 Compare May 28, 2026 21:55
@keeganwitt

Copy link
Copy Markdown
Contributor Author

@keeganwitt maybe you could join one of the weekly SPIRE Contributor Sync so we can have a discussion around this PR?

Sure, I'll drop in next week (9 June).

…fe#4699)

Let multiple SPIRE servers in a trust domain share JWT signing key material so
the JWKS endpoint no longer accumulates one key per server. Sharing is opt-in
per KeyManager plugin via a `shared_keys` configuration block, supported by the
disk, AWS KMS, GCP KMS, and Azure Key Vault key managers.

For a shared key to collapse to a single JWKS entry:
- Derive the JWT/WIT key ID deterministically from the public key (reusing
  x509util.GetSubjectKeyID), so every server computes the same kid for the same
  key material.
- Dedup signing keys by kid when appending to the bundle, keeping the latest
  NotAfter, since each server computes its own expiry.

To keep HA key rotation correct, sharing is scoped to JWT keys only. X509 CA and
WIT keys remain per-server, namespaced by a server identifier (now required when
shared_keys is enabled), so a restarting server only discovers its own X509/WIT
keys plus the shared JWT keys and never adopts another server's CA journal.
Cross-server creation races are coordinated with a per-plugin distributed lock
and a freshness window.

Signed-off-by: Keegan Witt <keeganwitt@gmail.com>
Add a CLAUDE.md describing the repository build/test workflow and the shared
JWT signing key design (the deterministic kid, bundle dedup, JWT-only scoping,
cross-server locking, and the per-plugin discovery mechanics) so future work on
this feature can continue without prior context.

Signed-off-by: Keegan Witt <keeganwitt@gmail.com>
@keeganwitt keeganwitt force-pushed the too_many_jwks_keys branch from 6e9bb74 to ea2dc97 Compare June 10, 2026 03:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants